In .github/workflows/dev-release.yml around lines 44, 117 and 190 the workflow
references actions/cache@v3 which is deprecated; update each occurrence to
actions/cache@v4 to follow GitHub recommendations and ensure ongoing support and
security updates—locate the three uses at those line numbers and change the
version tag from v3 to v4.

In .github/workflows/dev-release.yml around lines 54 to 65 (and similarly at
127-138 and 200-211), the workflow sets package.json version from inputs without
validating the input format; add validation to ensure the provided version
matches your expected pattern (e.g., semantic versioning) before writing. Modify
the step to run a small validation routine in the shell/node snippet that tests
the input against a regex (or semver parser), exit non-zero and print a clear
error if invalid, and only update package.json when the version passes
validation.

In packages/shared/config/constant.ts around lines 4 to 11, the
toDialogExtensions function's implementation only strips a single leading dot
but the JSDoc promises extensions "不含点"; change the logic to remove all leading
dots from each extension (e.g., use a replace with a regex that strips leading
dots or loop until no leading dot remains) and update the JSDoc if needed to
reflect exact behavior; ensure the function returns each extension with all
leading dots removed.

In packages/shared/config/constant.ts around lines 17-19,
getVideoDialogExtensions currently calls toDialogExtensions(videoExts) on every
invocation causing repeated allocations; change it to compute the result once
and return a cached reference (e.g. a module-level const initialized by calling
toDialogExtensions(videoExts)) so subsequent calls return the same array
instance, preserving exported API and types.

In src/main/services/FileStorage.ts around line 405, the expression calls
getFileExt(filePath).slice(1) twice and uses loose equality; store the result of
getFileExt(filePath).slice(1) in a local variable (e.g., extRaw), compare using
strict equality (extRaw === 'jpg') and then set ext = extRaw === 'jpg' ? 'jpeg'
: extRaw; optionally normalize case with toLowerCase() when extracting extRaw.

In src/main/utils/__tests__/file.windows.test.ts around lines 184 to 233, the
macOS and Linux tests currently restore process.platform to a hardcoded 'win32'
which can break tests running on non-Windows machines; capture and store the
original process.platform at the start of each test, and when restoring, set
process.platform back to that saved original value (apply this change in the
macOS block around lines 203-207 and the Linux block around lines 228-232).

In src/main/utils/file.ts around lines 62 to 67, the getFileExt implementation
should be unified into a shared helper to avoid divergence between renderer and
main; move the function into packages/shared (e.g.,
packages/shared/src/file.ts), export it from the shared package entry, then
replace local implementations by importing the shared helper in both main and
renderer codepaths. Update import paths, remove the duplicated function from
src/main/utils/file.ts (or re-export the shared helper from there), and run
type-check/build to fix any import or export errors.

In src/main/utils/file.ts around lines 90 to 101, the fallback that builds an
extension from the full normalizedPath can misclassify dotfiles (e.g.
"/.bashrc") as having an extension; restrict the fallback to operate on the path
basename only and ignore a single leading dot: compute const base =
path.basename(normalizedPath), if base startsWith('.') and base.indexOf('.') ===
0 and base.indexOf('.', 1) === -1 then treat as no extension; otherwise split
base on '.' and take the last segment as the extension only if there is more
than one segment and the last segment is non-empty.

In src/renderer/src/utils/file.ts around lines 15 to 18, update the JSDoc to
explicitly state the behavior for dotfiles: clarify that hidden files beginning
with a dot (e.g., ".env") are treated as having no extension and the function
will return an empty string, matching Node's path.extname behavior; add a brief
note in the existing comment describing this edge case so callers know dotfiles
are considered extension-less.

In src/renderer/src/utils/file.ts around lines 20 to 45, the renderer
file-extension utility lacks unit-test parity with the main process; add a
Vitest test suite mirroring src/main/utils/__tests__/file.windows.test.ts that
covers the cases: "C:\\a\\b\\c.mp4" => ".mp4", "/a/b/c" => "", "/a/.env" => "",
"a.tar.gz" => ".gz", "a." => "", "" => "", and "C:/dir.with.dot/file" => "";
place tests under src/renderer/src/utils/__tests__/file.windows.test.ts, import
the renderer util, write assertions for each input->expected output, and run the
renderer test config to ensure they pass before opening the follow-up PR.

In src/renderer/src/utils/file.ts around lines 20 to 45, the current logic
treats dotfiles like ".bashrc" as having an extension; update the extension
detection to match Node/path.extname and the main getFileExt by ignoring a
single leading dot with no other dots. Concretely: after computing fileName and
parts, if fileName startsWith('.') and parts.length === 2 then return '' (no
extension); otherwise proceed with the existing validation and return '.' +
extension when valid.